home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001349_daemon _Fri Jun 18 13:22:59 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA26788; Fri, 18 Jun 93 13:23:01 MET DST
  3. Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA26784; Fri, 18 Jun 93 13:22:59 MET DST
  6. Received: from [138.250.1.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA22966; Fri, 18 Jun 1993 13:45:08 +0200
  8. Received: by xdm001 
  9.     id AA26867; Fri, 18 Jun 93 12:44:59 +0100
  10. Received: by xdm039 (5.57/4.7) id AA20840; Fri, 18 Jun 93 12:44:56 +0100
  11. Message-Id: <9306181144.AA20840@xdm039>
  12. To: www-talk@nxoc01.cern.ch
  13. Cc: ccprl@xdm001.ccc.cranfield.ac.uk
  14. Subject: Re: HTML+ support for eqn & Postscript 
  15. In-Reply-To: Your message of "Fri, 18 Jun 93 12:03:46 BST."
  16.              <9306181103.AA26138@xdm001> 
  17. Date: Fri, 18 Jun 93 12:44:54 BST
  18. From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
  19.  
  20. Being a technical university, maths is highly desirable for us.
  21.  
  22. >    o   trade-off of complexity versus coverage
  23. >    o   the impact of yet another standard for equations
  24. >    o   the large numbers of math symbols in use
  25. >    o   just how much code is needed for parsing/rendering?
  26. >    o   what to do with line mode displays
  27.  
  28. My answer would be "whatever TeX can do, use that". The best way to do
  29. that is to use TeX, either by displaying the output of an existing dvi
  30. viewer, e.g. xdvi, or make WWW browsers into TeX viewers (maybe limited
  31. to just mathematical TeX). What to do with char displays? Do what TeX
  32. does (I don't *know* what it does, I don't want to know, I just know
  33. that its users seem happy with it).
  34.  
  35. We use (amongst other things) DECWrite, which deals with equations by
  36. embedding limited, math only, TeX code (actually stored in a separate
  37. file), and translating it to DECwrite's internal format for final
  38. display. It works well. DEC saw no reason to invent a new format, and
  39. given that TeX already exists, I  see no point in reinventing it,
  40. either. Face it, the hard bit has been done - the browser author
  41. doesn't have to know what the Tex code *does*, simply hand the input to
  42. it and render the output. Yes, I know it's not trivial for browser
  43. authors, but my guess is that reinventing maths symbol processing for
  44. HTML would be worse. Do the TeX stuff in a separate process, if you
  45. like. Ghostscript takes this approach of separating viewer and processor, I believe.
  46.  
  47. The same arguments apply to eqn, for sites which use that. We don't,
  48. but the code exists as groff. Fine; lets use that. If WWW land goes for
  49. eqn, I'm sure it's not too difficult to translate existing TeX math to
  50. eqn math. And once we can embed eqn or Tex math, why not arbitrary
  51. troff/groff or TeX? This has the distinct advantage of handling native
  52. man pages and TeXinfo straight off. 
  53.  
  54. Finally - a limited set of math symbols just wouldn't work. Authors
  55. will stop using it as soon as they realised that bits of it failed to
  56. come out. An HTML+ math format would need to be as complete as TeX/eqn
  57. from day one, which is a tall order; otherwise its like only supporting
  58. the 20 most frequently used letters of the alphabet on the basis that
  59. they cover 98% of English text. True, but still not acceptable.
  60.  
  61. Peter Lister                                    p.lister@cranfield.ac.uk
  62. Computer Centre,
  63. Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
  64. Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875